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PROJECTM APPING ^ 

BACKGROUND OF THE INVENTION 

The present Invention relates to project management generally referred to as 
coordinating different tasks to be done or processed by different resources such as 
persons, departments or functions. 

SUMMARY OF THE INVENTION 

It is an object of the invention to provide tools or processes for improved project 
management The object is solved by the Independent claims. Preferred embodiments 
are shown by the dependent claims. 

A project according to the present invention comprises a plurality of tasks and a 
plurality of resources available for handling, executing or othenA/ise processing one or 
more of the tasks. Each task and each resource is described by a data record 
comprising one or more characteristic features, properties, etc. thereof. A relationship 
identifier can be associated to each task representing its relationship to one or more 
of the resources. Accordingly or alternatively, a relationship identifier can be associated 
to each resource representing its relationship to one or more of the tasks. 

Task can be e.g. manual activities, creative work, administrative work, technical testing, 
etc. 

Resource can be e.g. an individual person, a group of persons (such as a department, 
a division, a project team, etc., a function within the company (such as a department 
head, a project manager, an external consultant, etc.), a competency (such as 
electrician, physicist, biologist, CAD-designer, etc.), or any other designation of 
functional units within a project, including non-human resources such as machines and 
material. 

A relationship between task and resource can be e.g. an assignment (e.g. one 
resource is assigned to one task) or a non-assignment (e.g. one resource is NOT 
assigned to one task). In case of an assignment, the nature or kind of the assignment 
can be further specified e.g. by an assignment statement such as 'responsible' (i.e. this 
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resource assigned to this task is also responsible for or the owner of this task) or 
'participant* (i.e. this resource assigned to this task but with no specific responsibility, 
dominance or ownership for this task). In case of a non-assignment, the relationship 
identifier can e.g. be left open, omitted or ignored and only 'positive' assignments will 
5 be considered. In one embodiment, a non-assignment Is regarded as default, so that 
only positive assignments have to be specified. 

In a first embodiment of the invention, a processing unit receives the data records of 
the plurality of tasks and resources together with the respective relationship identifiers. 
For visually mapping the project, the processing unit then represents the plurality of 

10 tasks in a first dimension of a matrix and the plurality of resources in . a second 
dimension of the matrix. Each relationship identifier is represented at the 
Interconnection or point of intersection between each represented task and resource 
in the matrix, respectively. Thus, relationships between tasks and resources can be 
represented or illustrated efficiently allowing providing an improved project 

15 management. 

In one emt>odiment, only such relationship identifiers will be represented for (positive) 
assignments between resource(s) and task(s). Preferably, the relationship identifiers 
for (positive) assignments are represented as dots or the like. For better visualization, 
all relationship identifiers relating to one task might further be connected by a line or 
20 similar connection. Each different type of relationship might also be represented by a 
different type of relationship identifier, e.g. different sizes of dots or different 
geometrical figures. 

In another embodiment, the tasks are arranged in accordance to defined relationships 
between the tasks such as temporal relationships and/or priorities. Preferably, the 
25 tasks are arranged in temporal order so that tasks to be started earlier will be 
represented first in the matrix dimension. In other words, successive tasks will be 
represented in successive order along the first matrix dimension. This an^angement can 
significantly improve comprehensibility of the matrix. 

In another embodiment, dependencies between tasks are further indicated in the 
30 matrix. Preferably, successive and dependent tasks are indicated e.g. by a pointer or 
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an arrow pointing from one or more former tasks to the successive and dependent 
task(s). This Indication of dependencies in particular in combination with an adequate 
arrangement of the tasks (preferably in successive order). In one embodiment, such 
dependencies are indicated using adequate pointers (preferably arows), whereby the 
5 pointers are directed between dedicated or selected resources assigned to the 
respective tasks. Preferably, the pointers are directed between such resources 
assigned as being responsible or otherwise superior to the respective tasks. 

In a further embodiment, a plurality of resources Is grouped together and represented 
only as one resource group. If one member of the resource group has a certain 

10 relationship identifier with one task, the resource group represents that relationship 
identifier for that task. In case that the resource group has plural different relationship 
Identifiers with one task, the resource group preferably represents only one relationship 
Identifier for that task according to a predefined seiectton criteria. Selection criteria can 
be e.g. priority (preferably highest priority) or responsibility of an assignment (preferably 

15 highest responsibility). Preferably, resource groups are represented differently than 
other resources In order to clearly Indicate the grouped nature. Adequate tools, might 
be provided for transforming plural resources Into one resource group and vice versa. 

Accordingly or altematlvely, a plurality of tasks can be grouped together and 
represented only as one task group. If one member of the task group has a certain 

20 relationship identifier with one resource, the task group represents that relationship 
Identifier for that resource. In case that the task group has plural different relationship 
identifiers with one resource, the task group preferably represents only one relationship 
Identifier for that resource according to a predefined selection criteria. Selection criteria 
can be e.g. priority (preferably highest priority) or responsibility of an assignment 

25 (preferably highest responsibility). Preferably, task groups are represented differently 
than other tasks In order to cieariy indicate the grouped nature. Adequate tools might 
be provided for transforming plural tasks into one task group and vice versa. 

In a further preferred embodiment, the processing unit further analyses the matrix and 
provides a plausibility check. Potential failures detected by this plausibility check are 
30 preferably indicated directly In the matrix e.g. by modifying the current representation(s) 
associated with each potential failure. Such modification can be e.g. varying color or 
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shape etc. In one embodiment wherein the tasks are arranged in temporal order and 
dependencies between tasks are indicated, dependencies directing in reverse temporal 
order (e.g. one task is dependent on results of another task, but the other task 
starts/ends later) can be candidates for potential failures. By arranging the tasks with 
5 increasing start date and indicating dependencies e.g. by arrows, anrows pointing 
'backwards* in the sequence of successive tasks are likely to be potential failures. 

Another plausibility check can be for detecting 'isolated' tasks i.e. tasks having no 
successive task being dependent thereon or tasks having no dependency to a 
precedent task. In an example when indicating dependencies e.g. by arrows, tasks 
10 without arrows or tasks either only receiving or 'emitting* an arrow can represent such 
'isolated' tasks. 

A further plausibility check can be for detecting 'milestone-ignoring' task dependencies, 
i.e. a dependency of a later task to a former task when a milestone is in-between. A 
milestone in that sense means a task, which constitutes a control point within the 
15 project and Is typically attributed a defined date. 

In a further embodiment, the processing unit provides an indication for which tasks are 
milestones. Preferably, a milestone would be visible by a readily visible border around 
the entire task, or by a gray or colored shading which accentuates this task in a visual 
manner. 

20 In another embodiment, the processing unit further provides an indication for the state 
of one or more of the tasks. Different states can be e.g. 'not started', 'pending', 
'finished', 'cancelled', 'postponed', 'skipped', 'due', 'overdue', 'in-time', 'experiencing 
difficulties', 'running as foreseen', 'on schedule', or 'over time'. Preferably, different 
states are indicated in different colors, e.g. 'green = In-time', 'yellow = experiencing 

25 difficulties', 'red = over time'. 

In one embodiment, the tasks are represented by parallel lines in the first matrix 
dimension, and the resources are represented by parallel lines in the second matrix 
dimension. The first matrix dimension preferably Is substantially perpendicular to the 
second matrix dimension. 
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In a further embodiment, two or more different but somehow related projects are 
provided in a joint representation, wherein preferably the first matrix dimensions of all 
projects are represented substantially parallel to each other and, accordingly, the 
second matrix dimensions of all projects are also represented substantially parallel to 
5 each other. In this case, one of the matrixes (preferably the one on the right hand side 
of the diagram) may be min^red such that the matrixes appear back-to-back. 
Dependencies between tasks of different projects can be indicated in the joint matrix 
substantially in accordance with the above said. Preferably, such dependencies are 
Indicated using adequate pointers (preferably arrows). 

10 In yet another embodiment of the invention, the processing unit receives information 
about an actually provided visual mapping of the project, and the processing unit 
derives therefrom the data records of the plurality of tasks and resources together with 
the respective relationship Identifiers. For that purpose, the processing unit analyses 
the representations of the plurality of tasks in the first dimension of the matrix and the 

15 plurality of resources in the second dimension of the matrix together with the 
representation of each relationship Identifier at the Interconnection between each 
represented task and resource in the matrix, respectively. This is in particular useful 
in case data records have been modified in the represented matrix, e.g. by. user 
intervention or under influence of a different tool or software. However, even entirely 

20 new matrix representations (e.g. provided or designed by users) can thus be 
'transformed' into machine-processable data records. It is clear that any additional 
information e.g. as introduced in the above embodiment, such as relationship types or 
dependencies, can thus be 'transformed' accordingly into the data records. 

The invention can be partly or entirely emt)odied or supported by one or more suitable 
25 software programs, which can be stored on or othenA^ise provided by any kind of data 
carrier, and which might be executed In or by any suitable data processing unit. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other objects and many of the attendant advantages of the present Invention will be 
readily appreciated and become better understood by reference to the following 
30 detailed description when considering In connection with the accompanied drawings. 
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Features that are substantially or functionally equal or similar will be referred to with the 
same reference slgn(s). 

Figs. 1A-D illustrate principles of the Invention. 

Figs. 2A and B illustrate in detail a preferred embodiment of the Invention. 

5 DETAILED DESCRIPTION OF THE INVENTION 

Fig. 1 Illustrates the invention in an example of a project comprised of five tasks 
TASK01-TASK05 to be handled by seven resources RESOURCE01 -RESOURCED?. 
Each task and each resource is described by a respective data record including 
relationship identifiers representing the assignments of resources to respective tasks. 

10 A processing unit (not shown) receives the data records and represents the tasks 
TASK01-TASK05 in a first dimension of a matrix and the resources RESOURCE01- 
RESOURCE07 in a second dimension of the matrix. In the example of Fig. 1 A, the first 
dimension is the x-axis of a 2-dimensional matrix and the second dimension is the y- 
axls thereof. Each relationship identifier is represented at the interconnection between 

15 task and resource in the matrix. In the example of Fig. 1 A. a (positive) assignment of 
a resource to a respective task is represented by a dot, while a non-assignment (i.e. 
the resource is not assigned to this task) is considered as default and not further 
indicated. 

In the example of Fig. 1A, task TASK01 is to be processed by assigned resources 
20 RESOURCE01 and RESOURCE05, task TASK02 is to be processed by assigned 
resources RESOURCE02, RESOURCE03, and RESOURCED?, etc. 

Fig. IB shows an alternative representation for the project example shown in Fig. 1A. 
First difference is that the type of assignment is further specified by indicating with a 
bigger dot the assignment of that resource responsible for that task and with a smaller 
25 dot the simple assignment of that resource to that task without having the responsibility 
thereof. Second difference Is that all relationship Identifiers relating to one task are 
connected by a thick line for better visualization. 

Third difference is that dependencies between tasks are further indicated by anrows in 
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the matrix. In the example of Fig. IB, the execution of task TASK02 requires results 
from task TASK01. This is indicated by an arrow from resource RESOURCE05 
assigned as responsible for task TASK01 to resource RESOURCE03 assigned as 
responsible for task TASK02. Accordingly, results from task TASK02 are to be reported 
5 to resource RESOURCE07 assigned as responsible for tasks TASK03 and TASK04. 
Eventually, results from task TASK05 are also to be reported to resource 
RESOURCE07 assigned as responsible for task TASK04. 

In Older to improve comprehensibility of the matrix, the tasks are arranged along the 
y-axis in successive order Indicating that task TASK01 is to be started or processed 
1 0 before task TASK02, task TASK02 is to be started or processed before task TASK03, 
etc. 

The processing unit might further analyze the matrix and provide a plausibility check 
for potential failures. In the example of Fig. 1B, it is detected that task TASK04 is 
dependent on results of task TASK05. but task TASK05 starts/ends later than task 
15 TASK04. Such anow pointing 'backwards' is likely to be a potential failure and will 
therefore be indicated by a dotted or othenwise accentuated line. A user can then 
further analyze the dependency between tasks TASK04 and TASK05 and might 
correct that (e.g. that task TASK05 becomes dependent on results of task TASK04). 

Fig. 1C illustrates an embodiment for the example of Fig. 1B, wherein resource 
20 RESOURCE07 represents a group of individual resources RESOURCE07A- 
RESOURCE07D,- and task TASK05 represents a group of individual tasks TASK05A- 
TASK05D. While Fig. IB shows the groups as such, the illustration of Fig. 1C depicts 
all individual tasks and resources of the groups. 

Fig. 1D shows an example wherein two related projects are provided in a joint 
25 representatkjn. Dependencies between tasks of the different projects are indicated by 
arrows. 

While Figs. 1 illustrated basic examples, a more detailed example shall now be 
considered in conjunction with Figs. 2A and 2B. The project mapping diagram 
presented here shall now be referred to as Matrix. 
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Data needed for the elaboration of the Matrix are preferably kept in a database or a file 
containing information concerning the project, as shown in Table 1 below. Examples 
are provided for data formats Microsoft Project (.mpp) and Primavera Project Planner 
for the Enterprise (P3e), 



Data field in ' • ! Data Type 
database or file 

Unique identifier for numerical 
task 



Examples for mapping 
{. (.mppand P3e) 

Unique ID 
taskJD 



Explanation 



Unique task ID number 



WBS Code Hierarchical ; WBS or Outline jo. 

numbering I . 

, / , 'wbsjd 
,.(.mpp)or 

i ; 

' alphanumerical 
.(P3e) ii 

1 1 ■ 
•i 

Task name alphanumerical Name (Task table) 

tasl^name 



Work Breakdown Structure 
Code 



Name of the task 



Status 



Predecessors 



i; alphanumericai 



numerical 



'r 



status or other 
status.code or other 
Unique ID Predecessors 



Cunent status of task 



List of all tasks of which 
the cunrenttask is 
dependent (has a 
predecessor-successor 
dependency relation). 
(Successor infomiation is 
calculated out of 
predecessor infomiation 
and therefore redundant) 



Milestone 



Boolean 



! Milestone 



Task is a milestone if 
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' value = 1 or task_type= ' 
•I milestone 

ji. • : 

Person participating in 
task 

: Department participating 
in task 

Competence of person in 
the context of the project 

! ^ Resource, department, or 
role responsible for the 

: elaboration of the task 

! 

Table 1 

Using the data contained in the database or file, the representation according to the 
present invention can be generated as the IVIatrix of the project, as illustrated in Figs. 
2A-B. The Matrix lists the different tasl<s of the project from top to bottom, and with 
5 several alphanumeric fields (columns) on its left side. 

Each of the data fields in Table 1 needed for the Matrix will now be described in detail. 
The first three fields are used to determine the text in the left-hand side of the Matrix 
(see Figs. 2A-B) while the other six fields determine how the right hand side of the 
Matrix (see Figs. 2A-B) will be drawn graphically. 

10 Unique ID (Unique ID): The identification number ID is a number issued automatically 
during the planning of the project by the user. In the case of the Unique ID number, this 
number never changes, even when the task order Is changed by the user. Therefore, 
Unique ID can be used as a key to keep track of tasks even when their order is 
changed. The Unique ID is preferably not displayed in the Matrix. 

15 WBS-Code (WBS): The work breakdown staicture (WBS) is a classic technique of 
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Resource 



Department 



Role 



. ;. task^type 

alphanumerical Resources 
taskrsrc 

alphanumerical Resource group . 

OBS, resource codes 

alphanumerical User-defined fields 
role 



Responsible. 



; I Responsible 
person 



First resource 



primary resource 
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project management with which the overall objective of a project is divided into several 
manageable tasks. The WBS-Code is a hierarchic code: a task with a number 2 (see 
Figs 2A), for Instance, can have several subtasks 2.1, 2.2, 2.3, etc. (see Fig. 2B). 
Subtasks can be further divided into subtasks such as 2.1.1, 2.1.2, etc. The WBS- 

5 Code for a task is to be displayed in the first column of the Matrix (note that tasks and 
subtasks have a different length In their WBS-Code due to the hierarchic 
representation, but the unique ID-Number of any specific task will always be only one 
number. This number will remain unchanged when the task is made to a subtask or 
summary task or even when its order within the project is changed). The WBS-Code 

1 0 will be of further importance for the functionality of showing and hiding the subtasks of 
a summary task (see below). 

Name (Name): The name of the task is the second column to be displayed on the left 
side of the Matrix. It simply specifies what Is to be done in the task. 

The Matrix therefore begins with two or more alphanumeric columns. Adjacent to these 
1 5 columns, columns representing the resources of the project are introduced; as are dots 
and anovy^ to illustrate the communication flow in the project. The following data fields 
detemnlne thie graphical representation of this right hand side of the Matrix. 

Using the data contained in the database or file, many different types of Matrixes can 
be drawn by using resources, departments, roles, or any other attribute of the actors 
20 In the project to define the right hand side of the Matrix. Each actor of the project is 
represented by a column on the right hand side of the Matrix. The following 
explanations will concentrate on the firet kind of Matrix using resources as column 
titles. All other Matrix types are elaborated In the same manner and will be described 
aftenvards. 

25 Once the columns have been defined, dots and arrows can be added to illustrate the 
assignments and dependencies In the project. The following fields provide the 
necessary information to do so. 

Resources: All resources active in the task are marked by a dot. 

Responsible: The responsible resource in each task is marked with a large black dot. 
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When there is more than one participating resource in a tasl<, all participating and 
responsible resources may be connected with a black line. 

An-ows are drawn between the responsible resource of a preceding task to the 
responsible of a subsequent task. The horizontal position of an amw is thus 
5 detennlned by the infomnation contained in each task. All arrows from preceding tasks 
are therefore to go to the large dot representing the responsible, and arrows going to 
succeeding tasks shall originate from this large dot (this is the case when the 
"Predecessors" fields of other tasks point to the cun-ent task). 

Status: The user enters the current status of each task into this field. The processing 
10 unit of the system interprets the data of this field to display an intuitively 
comprehensible dot of a corresponding ^color, e.g. 'green = in-time', 'yellow = 
experiencing difficulties', 'red = over time'. 

Milestone (Milestone): This Boolean field is active when a task is a so-called milestone 
of a project. In this case, the task preferably appears in gray shading and with a border 
15 around it. Examples for milestones are Tasks 3 and 16 in Figs. 2A-B. The text of the 
milestone preferably appears In bold print. 

Summary tasks: Summary tasks regroup several subtasks to a larger task. This Is 
important for a project manager in order to mask unnecessary detail, e.g. when he Is 
trying to get an oven/lew over a larger project. The notion of summary tasks and 
20 subtasks is closely related to that of WBS (work breakdown stmcture), with which a 
project is first broken down into larger tasks (sometimes called work sections) and then 
further into smaller tasks (see chapter on "WBS"). 

In one embodiment, the user has the possibility to hide and show subtasks of a project, 
e.g. in order to view particular parts of a project in greater detail, while seeing only the 
25 summary tasks of parts which are of less importance. In this embodiment, summary 
tasks have a little box displayed next to their name so the user understands that these 
particular tasks contain subtasks. When the user clicks on one of these boxes with the 
"+" sign (see Task 2 In Fig. 2A), the sign changes to and the subtasks are shown 
(see Task 2 in Fig. 2B). When the user clicks on one of the boxes to open a summary 
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task and show its subtasks, the arrows and dots in the Matrix change. Any resource 
participating In one of the subtasks (responsible or not) now appears as a dot in the 
collapsed summary task, i.e. when the subtasks are hidden. In a further embodiment, 
a specific field is defined for the responsible resource of a summary task. Whichever 
5 resource is responsible for the summary task preferably appears as a large dot or 
whatever other graphical Indicator may be found appropriate. 

Since a summary task Is in itself not an independent task but only an aggregation of 
several subtasks, the communication anrows preferably no longer go through the 
summary task when Its subtasks are visible. However, direct communication an-ows 
10 between summary tasks could exist if the user defined them explicitly. When 
communication anrows are defined directly with summary tasks, their communication 
arrows preferably still go out of the summary task even when subtasks become visible. 

Since subtasks can be under the responsibility of several different resources, the 
responsible of each summary task needs to be defined separately. A summary task 
15 can even be under the responsibility of a resource that is not responsible for any of its 
subtasks, e.g. \ftrtien a resource is responsible as a coordinator for the summary task. 
When the subtasks of a summary task are shown, the Responsible System Function 
of the summary task is preferably marked with a large circle or another graphical 
indicator found appropriate rather than a large dot to prevent misunderetandlngs. 

20 When the user clicks on the box of a summary task to expand it, the communication 
an-ows going to or originating from subtasks preferably no longer go to the summary 
task, but directly to the subtasks and their responsible functions. 

The following tables Table 1 and Table 2 explain In detail the tasks of the Figs. 2A and 
2B, whereby Table 1 con-esponds to Fig. 2A and Table 2 con-esponds to Fig. 2B. The 
25 WBS-numbers link the respective tables and figures, so that e.g. the WBS-number 1 
in Fig. 2A con^sponds to the task "SWOT analysis" with the infomiation "Strengths and 
weaknesses of the company " In Table 1. 
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WBS 


Task 


Information 


0 


MS 0: Kick-Off Decision 


Go! 


1 


SWOT analysis 


Strengths and weaknesses of the company 


2 


Definition of present business fields 
of the company 


List of business fields 


3 


MS 1: Wliich and how many 
business fields should the company 
pursue? 


Which present and potential business fields 
exist? Definition of future market strategy. 


4 


Appointment of chairmen of each 
strategy circle 


Chairman of each strategy circle 


5 


Call for participation in strategy 
circles 


Complete list of members for each strategy 
circle 


6 


Strategy circle meetings 


List of opportunities 


7 


Market identification for business 
field 


List of markets served and ignored 


8 


Analysis of refused offers 


List of refused offers including reasons for 
refusal. 


9 


Investigation of potential markets 
within business field 


List of potential markets in Spain and abroad 


10 


Analysis of competition 


List of universities, institutes and companies 
liable to serve similar customer needs 


11 


Identification of missing 
competencies and resources w/ 
regard to targeted markets and 
customers 


List of missing competencies and resources 
and proposal for cooperation or other solutions 
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12 


Analysis of earnings potential 
(profitability) by groups of customers 


infomnation concering surplus creation, 
possible pricing policy. 


13 


New business opportunities 


List of other business fields that have 
appeared due to the in-depth investigation of 
the market 


14 


Analysis of possibilities to protect 
knowledge in the business field 


Industrial property protection suggestions 


15 


Drafting of final report for business 
field 


Business field report 


16 


MS 2: Decision on future action 


Are any important business fields not 
covered? List of served, missed, potential 
markets and refused offers. Analysis of 
competition, missing competencies, 
suggestion for cooperations. 



Table 1 
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WBS 


Task 


Information 


0 


MS 0: Kick-Off Decision 


Go! 


1 


SWOT analysis 


Strengths and weaknesses 


2 


Definition of present business fields 
of the company 


List of business fields 


2.1 


Brainstomriing event to identify new 
business fields 


New potential business fields 


2.2 


Delimitation of business fields 


Exact definition of each business field 


2.3 


Definition of possible Marketing 
strategies 


Scenarios of different marketing strategies 


2.4 


Definition of terms of reference for 
"strategy circles" 


Terms of reference, goals and composition of 
SC's 


3 


MS 1 : Which and how many 
business fields should the company 
pursue? 


Which present and potential business fields 
exist ? Definition of future market strategy. 


4 


Appointment of chairmen of each 
strategy circle 


Chairman of each strategy circle 


5 


Call for participation in strategy 
circles 


Complete list of members for each strategy 
circle 


6 


Strategy circle meetings 


List of opportunities 


7 


Market identification for business 
field 


List of markets served and ignored 


8 


Analysis of refused offers 


List of refused offers including reasons for 
refusal. 
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9 


Investigation of potential markets 
within business field 


List of potential markets in Spain and abroad 


10 


Analysis of competition 


List of universities, institutes and companies 
liable to serve similar customer needs 


11 


Identification of missing 
competencies and resources w/ 
regard to targeted markets and 
customers 


List of missing competencies and resources 
and proposal for cooperation or other solutions 


12 


Analysis of earnings potential 
(profitability) by groups of customers 


Information concering surplus creation, 
possible pricing policy. 


13 


New business opportunities 


List of other business fields that have 
appeared due to the In-depth Investigation of 
the market 


14 


Analysis of possibilities to protect 
knowledge in the business field 


Industrial property protection suggestions 


15 


Drafting of final report for business 
field 


Business field report 


16 


MS 2: Decision on future action 


Are any important business fields not 
covered? List of served, missed, potential 
markets and refused offers. Analysis of 
competition, missing competencies, 
suggestion for cooperations. 



Table 2 
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